%!TEX root = main.tex
\section{Introduction}
\begin{itemize}
\item what's NDNS: storage in NDN; and design goals of NDNS: scalability, universality, and origin authentication
\item hierarchical structure to scale up lookup for scalability
\item no restriction on the content format stored in NDNS for universality
\item hierarchical trust model for authentication
\item public service: query and update
\item inspired by DNS, extension of Alex's thesis work
\item report organization
\end{itemize}

\section{Comparison between NDNS and DNS}
\begin{itemize}
\item Basic design of DNS: preliminary goal, tree-like namespace, zone, name server, cache resolver, master-slave and zone transfer.
\item queries: recursive and iterative
\item great success due to: universality, scalability, autonomy and robustness, immediate need.
\item following works, DNSSEC, DynDNS, AXFR/IXFR, EDNS0/EDNS(0).
\add{probably should add some use cases: DANE, DNS blacklist and whitelist, multicast DNS, DNS-based service discovery}
\item NDNS inherits design from DNS, but big differences due to fundamental difference between IP and NDN
\item application-layer cache v.s. network layer cache; iterative query: zone hierarchy with jump v.s. domain name hierarchy
\item built-in security v.s. enhancement. RR self-contains its authentication information.
\item handle Update and zone transfer: master-slave v.s. multiple-master
\item RR limitation: DNS 512 bytes over UDP, and TCP with extra handshake cost; NDNS segments RR into multiple smaller Data packets, which can be transmitted by NDN.
\item NDNS allows multiple version of RR associated with specific domain name.

\item Definition of Domain namespace, Resource Record, name servers, zones,
\end{itemize}
\subsection{Caching \& Query}
\begin{itemize}
\item IP and TCP/UDP cannot identity  content permanently. Caching relies on application-layer info. Thus, DNS needs caching resolvers process  application-layer info, cache and reuse data; queries should contain as much information as possible; servers is smart (and complex) enough to find the best-match, this leads to zone hierarchy and possible zone jump.
\item Example to show iterative query in DNS
\item NDN names content directly and leverages network cache on routers. Routers can do name-base match only.
\item Excessive info does not help the cache match on routers, on the contrary, reduce the possibility to reuse cached data
\item NDNS iterative query follows the domain name hierarchy of the target domain name. In this case, referral to a zone's name server could be reused to serve requests finally targeting to the zone and its descendants. And queries to root zone and its children are most likely to be satisfied by cache.
\item Caching resolver in NDNS is not as important as it is in DNS.
\end{itemize}
\subsection{Security \& Update \& Zone synchronization}
\begin{itemize}
\item DNSSEC intro: RRSIG, DNSKEY, DS, NSEC, trust model
\item NDNS follows the similar way. but 1) RR self-contained authentication info, instead of extra resource record. 2) certificates are referred by name directly.
\item online signing is needed
\item Secure DynDNS, Mode A and Mode B
\item NDNS follows Mode A without causing problem of zone synchronizaiton and non-existence of RR
\item NDNS name servers in a zone are peering with each other, any server could handle update for robustness and scalability, due to more and more mobile devices and emerging requirement for mobility support.
\item AXFR and IXFR follows master-slave, while NDNS follows multiple-master.
\item DNS message transmitted over TCP with 3-way handshakes for connection and a pair of 2-way handshake for termination, over UDP with size limitation. EDNS0 and EDNS(0) advertise their capabilities to responders.
\item master-slave for zone transfer AXFR/IXFR, multiple-master reokucatuib nidek fir zone synchronization
\end{itemize}

\subsection{Segmenting \& Versioning}
\begin{itemize}
\item DNS transmitted over TCP with cost: 3-way handshake and a pair of 2-way handshake; over UDP with size limitation. EDNS0 and EDNS(0) to advertise size capability.
\item NDNS segments large RR into multiple Data; no-handshake; size boundary is on-going research of NDN
\item versioning is requirement of immutable data model, also extends the adhibition of NDNS.
\end{itemize}

\section{Design of NDNS}
\subsection{Overview of NDNS}
\begin{itemize}
\item the NDNS system including name server, caching resolver, stub resolver connected via NDN network (Figure 1)
\item NDNS messages, Query/Response, Update/Result.
\item two kinds of Response: NDNS-RESP and NDNS-NACK; and two pre-defined RR: NS, ID-CERT.
\item NS RR is defined to be the referral to name servers in children zone; example, and NDNS-AUTH
\item ID-CERT is used to store certificates.
\item Query and Update
\end{itemize}
\subsection{ Naming Convention}
\begin{itemize}
\item Query/Response Naming (Table 1 \& example, Figure 2)
\item Update/Result Naming.
\end{itemize}

\subsection{NDNS Query}
\begin{itemize}
\item Two kinds of queries, iterative \& recursive
\item Working flow of NDNS query (Figure 3)
\item Iterative Query: two stages and example
\item Two types of pre-defined RRs, ID-CERT \& NS
\end{itemize}

\subsection{NDNS Update}
\begin{itemize}
\item Update is started on client side, and handled by server side.
\item security must be handled very carefully. verification rules: 1) Update generated by authorized producer; 2) Update is not duplicated or due to replay attack; 3) embedded RR is generated by authorized producer; 4) RR does not violate immutable data model;
\item authorized identity must sign the Update and embedded RR
\item how to remove RR
\item replay attack and ``update version number'' to prevent the attack.
\end{itemize}

\subsection{Zone Synchronization}
\begin{itemize}
\item Zone instances differ when update
\item How to by ChronoSync: broadcast group, state and update triggers Interest from other.
\end{itemize}
\subsubsection{Zone Synchronization Based Update}
\begin{itemize}
\item authorized identity acts like a name server to signal name servers to fetch update
\item pull-style communication
\item pre-conditions of this way.
\end{itemize}

\subsection{ Trust Model}
\begin{itemize}
\item KSK and DSK;
\item Issuer of certificate and owner of key could be inferred from certificate
\item Hierarchical trust model with example
\item Verify RR in NDNS
\item verify Data packet signed by the certificate stored in NDNS
\item ref: 3 steps to secure network content.
\item certificates in NDNS binds the certificate to identity.
\end{itemize}



\section{Implementation}
\subsection{ Database}

- Table zones scheme

- Table rrsets scheme

\subsection{NDNS Message Format}
\begin{itemize}
\item Query, with Table 4 to show Application tags
\item Iterative Query Response
  1) NdnsMetaInfo
  2) Content Field
  3) Signature Field
\item Recursive Query Response
\item Update Message
\item Update Response Message
\end{itemize}

\section{Management}
NS \& ID-CERT are the most common manipulated objects
Management toolset
\begin{itemize}
\item ndns-add-rr
\item ndns-add-rr-from-file
\item ndns-create-zone
\item ndns-delete-zone
\item ndns-export-certificate
\item ndns-get-rr
\item ndns-list-zone-zones
\item ndns-list-zone
\item ndns-remove-rr
\end{itemize}
\subsection{Usage}
- zone creation

- zone delegation

\section{Deployment}
NDNS platforms, download and install
\subsection{ Use Cases}
\begin{itemize}
\item content verification (*add NDN-based Video Player*)
\item routing scalability
\item mobility support
\end{itemize}

\section{Summary}

this report propose NDNS, which inherited basic design from DNS/DNSSEC and serves NDN as DNS/DNSSEC does to TCP/IP.

\end{document}